Virtualization of mobile device user experience

ABSTRACT

A device virtualization service (DVS) is provided that uses a generalized thick client resident on a mobile device to provide user interface generation support to a myriad of services providing mobile device content. The DVS abstracts device specifics from services to provide device independent user experiences to be described by the service and then rendered on the device.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.14/053,539 filed Oct. 14, 2013, which is a continuation of U.S. patentapplication Ser. No. 11/474,303 filed on Jun. 23, 2006, now U.S. Pat.No. 8,560,595 issued Oct. 15, 2013, the entirety which is incorporatedherein by reference.

BACKGROUND

User satisfaction with a program, application, or service running on amobile device often depends on the user interface (UI) associated withthe mobile device. With some mobile devices, a UI is supplied to amobile device via the Internet. With web-based provisioning of a userinterface, a web page is built on a server and provided to the userthrough the web browser available on the mobile device. Theinteractivity between the user and the web page is limited to thebrowser's rendering capabilities, which also limits the interactivitybetween the user and the program. Mobile devices also have a limitedbandwidth of communication. A lower bandwidth can create higher latencyfor the receipt and transmission between the web page produced on theuser's mobile device and the application resident on an external server.

A UI may also be associated with a mobile device by downloading theentire program or application to the mobile device. The entire programmay consume a large portion of the memory of the mobile device. Also, aUI may be associated with a mobile device by downloading a “thickclient” to the mobile device. The variety of mobile devices availableand the variety of thick clients may result in compatibility problemsthat arise as these types of clients are used. Also, building a thickclient for each of the various mobile device results in development,testing and economic inefficiencies.

SUMMARY

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

A device virtualization service provides a generic thick client to amobile device. The generic thick client facilitates providingcustomizable user interfaces on multiple mobile device platforms withoutrequiring the developer to generate the user interface to writespecialized code for each mobile device model. In this manner, Internetservices may provide data and information to mobile devices withoutregard to the type of device on which the information is being rendered.

BRIEF DESCRIPTION OF THE DRAWINGS

Non-limiting and non-exhaustive embodiments of the present invention aredescribed with reference to the following figures, wherein likereference numerals refer to like parts throughout the various viewsunless otherwise specified.

FIG. 1 illustrates an exemplary computing architecture for a computer;

FIG. 2 illustrates an exemplary system for providing a devicevirtualization service;

FIG. 3 illustrates an operational flow diagram for provisioning a mobiledevice for accepting service data using a device virtualization service(DVS);

FIG. 4 illustrates an operational flow diagram of an exemplary processfor the operation of a DVS server; and

FIG. 5 illustrates a screen shot of a service user interface screenrendered by the generalized thick client, in accordance with the presentdisclosure.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

Embodiments are herein described more fully below with reference to theaccompanying drawings, which form a part hereof, and which show specificexamples for practicing the embodiments. However, embodiments may beimplemented in many different forms and should not be construed aslimited to the embodiments set forth herein; rather, these embodimentsare provided so that this disclosure will be thorough and complete, andwill fully convey the scope of the subject matter to those skilled inthe art. Embodiments disclosed may be practiced as methods, systems ordevices. Accordingly, embodiments disclosed may take the form of anentirely hardware implementation, an entirely software implementation oran implementation combining software and hardware aspects. The followingdetailed description is, therefore, not to be taken in a limiting sense.

When reading the discussion of the routines presented herein, it shouldbe appreciated that the logical operations of various embodiments areimplemented (1) as a sequence of computer implemented acts or programmodules running on a computing system and/or (2) as interconnectedmachine logic circuits or circuit modules within the computing system.The implementation is a matter of choice dependent on the performancerequirements of the computing system implementing the invention.Accordingly, the logical operations illustrated and making up theembodiments described herein are referred to variously as operations,structural devices, acts or modules. These operations, structuraldevices, acts and modules may be implemented in software, in firmware,in special purpose digital logic, and any combination thereof.

Referring now to the drawings, in which like numerals represent likeelements, various aspects of the present invention will be described. Inparticular, FIG. 1 and the corresponding discussion are intended toprovide a brief, general description of a suitable computing environmentin which embodiments of the invention may be implemented.

Generally, program modules include routines, programs, components, datastructures, and other types of structures that perform particular tasksor implement particular abstract data types. Other computer systemconfigurations may also be used, including hand-held devices,multiprocessor systems, microprocessor-based or programmable consumerelectronics, minicomputers, mainframe computers, and the like.Distributed computing environments may also be used where tasks areperformed by remote processing devices that are linked through acommunications network. In a distributed computing environment, programmodules may be located in both local and remote memory storage devices.

Referring now to FIG. 1, an exemplary computer architecture for acomputing device 100 utilized in various embodiments will be described.The computer may be configured as a personal computer, a mobile computerand the like. As shown, computing device 100 includes a centralprocessing unit 102 (“CPU”), a system memory 104, including a randomaccess memory 106 (“RAM”) and a read-only memory 108 (“ROM”), and asystem bus 116 that couples the memory to the CPU 102. The computingdevice 100 further includes a mass storage device 120 for storing anoperating system 122, application programs, and other program modules,which will be described in greater detail below.

The mass storage device 120 and its associated computer-readable mediaprovide volatile and non-volatile storage for the computing device 100.The computer-readable media may include any type of removable and/ornon-removable media.

The computing device 100 operates in a networked environment usinglogical connections to remote computers through a network 112, such asthe Internet. The computing device 100 may connect to the network 112through a network interface unit 110 connected to the bus 116.

The computing device 100 may also include an input/output controller 114for receiving and processing input from a number of devices, such as: akeyboard, mouse, electronic stylus and the like. Similarly, theinput/output controller 114 may provide output to a display screen, aprinter, or some other type of device (not shown).

As mentioned briefly above, a number of program modules and data filesmay be stored in the mass storage device 120 and RAM 106 of thecomputing device 100, including an operating system 122 suitable forcontrolling the operation of a networked computer. The mass storagedevice 120 and RAM 106 may also store one or more program modules. Inparticular, the mass storage device 120 and the RAM 106 may store adevice virtualization service (DVS) module 124.

The configuration of DVS module 124 is dependent on whether thecomputing device has been configured as a service provider server thatprovides service data and interaction, a DVS server that configures datafor transmission to a mobile device, or a mobile device itself. For aservice provider computing device, DVS module 124 provides configurationfiles and communication protocols for communicating data to the DVSserver in a generalized format. For DVS server, DVS module 124 providestranslation and packaging configuration data for translating datareceived from the service server. The DVS module 124 packages the datafor efficient transmission to the mobile device. For the mobile deviceitself, DVS module 124 may include a thick client application forrendering the resulting user interface on the screen of the mobiledevice. A thick client (also known as a fat client or rich client) is aclient that performs data processing operations, and relies on anassociated server for data storage.

Throughout the specification and claims, the following terms take themeanings explicitly associated herein, unless the context clearlydictates otherwise. In some aspects, “Device Virtualization Service” or“(DVS)” refers to any portion of a network configuration, whetherreferring to the server side or client side in the communication, forgenerating a user interface on a mobile device from generalized datapassed through a DVS server.

In some aspects, “DVS server” refers to a server that is configured toobtain generalized data from services, facilitate translating andpackaging the generalized data into an optimized format, facilitateforwarding the optimized data to a mobile device, facilitate eventhandling for communication between the mobile device and the service, aswell as perform other additional tasks.

In some aspects, “Event” refers to an interaction with the userinterface rendered on the mobile device that triggers communication backto and from the service associated with the user interface.

In some aspects, “Widget” refers to a user interface element forproviding a user experience (UX). As one exemplary definition for awidget, a widget may be an interface component such as a display frameor a text box.

The Device Virtualization Service (DVS) facilitates projecting a userexperience (UX) onto a mobile device. In one embodiment, the DVSprovides an interface (API) that allows the service to provide a set ofUser Interface (UI) pages which in turn lay out widgets of those pages.The widgets may include data tables for efficient storage of the dataincluded on the pages. The Device Virtualization Service (DVS) abstractsdevice specifics from services that want to expose an end-userexperience on the device. The DVS provides a device independent UX to bedescribed by the service and then rendered on the device. The DVS mayalso enable a service to obtain device capabilities such as screen size,audio and video COmpress/DECompress technology (CODEC) supported so thatthe service can provide appropriate media to the device.

FIG. 2 illustrates an exemplary system for providing a devicevirtualization service, in accordance with the present disclosure. Thesystem includes service 202, DVS server(s) 204, and mobile devices(e.g., 206).

Service 202 may correspond to a service for providing media, or anotherservice for providing news or sports headlines. The particular type ofservice may vary without affecting the scope or applicability of thedisclosure. Service 202 may be physically represented by a server orother computing device that stores and manages data. particular to theservice and is responsible for communication of the data to otherdevices.

DVS server 204 is configured to receive data from service 202, packagethe data for transmission, transmit the data to the mobile device (e.g.,206) for rendering, handle events that occur on the mobile device, andcommunicate those events. A more detailed discussion of the operation ofDVS server 204 is provided below in the discussion of FIG. 3.

Once the packaged data is received at the mobile device (e.g., 206), themobile device uses a DVS generalized thick client to render the data.The generalized thick client may render a user interface for multipleservices without having customized programming resident on the mobiledevice for each service. A more detailed discussion of the processesinvolved for system 200 are provided below in the discussion of FIG. 4.

FIG. 2 does not depict an exhaustive representation of the elementsassociated with a DVS. Additional or fewer elements may be included andthe DVS still operate for its intended purpose. For example, in analternative embodiment, a service provides programs for storage on a DVSserver so that communication is provided directly between the DVS serverand mobile devices subscribed to the service. In such an alternativeembodiment, the DVS server does not need to forward the data to theservice provider.

An application programming interface (API) allows the service to obtaina set of device characteristics to customize the data it provides for aspecific mobile device. For instance, the service may determine thepixel resolution of the device, the media formats the device supports,which media settings provide the optimal device playback, and the like.

A typical service, such as a music service, often provides a series ofpage layouts for the various different portions of their serviceexperience. For example, the music service may include a browse byartist page, a browse by genre page, and the like. The music service mayalso provide a media preview page and a purchase confirmation page. Thenavigation between the pages is defined by behaviors attached to one ormore widgets on the pages. In this way, the service has substantialcontrol over the flow of the UI.

FIG. 3 illustrates an operational flow diagram for provisioning a mobiledevice for accepting service data using the device virtualizationservice (DVS). Process 300 starts when a mobile device user has selectedto subscribe to a particular service (e.g., a music service). Processingcontinues at operation 302.

At operation 302, a message is sent to the mobile device with a networkaddress where the mobile device can locate and download the generalizedthick client. In one embodiment, the DVS server sends the mobile devicea Short Messaging Service (SMS) message that includes a Uniform ResourceLocator (URL) that indicates a location for downloading the generalizedthick client. Processing continues at operation 304.

At operation 304, the user selects or clicks on the URL sent in the SMSmessage to commence the download process that downloads the generalizedthick client to the mobile device. Processing continues at operation306.

At operation 306, an Internet service server or HTTPS serverauthenticates a User ID that was encoded in the URL sent to the user'smobile device. The authentication ensures that the mobile device thatsent the SMS message is the device receiving the downloaded clientapplication. A cookie is sent to the mobile device that includes theencrypted user ID and hash so that the mobile device is identified as anauthenticated mobile device for future communications. Along with thecookie, the generalized thick client is downloaded to the mobile device.Processing continues at block 308.

At block 308, the generalized thick client is installed on the mobiledevice. One or more installation wizards may be used for theinstallation, or other methods of installation may be used. Once thegeneralized thick client is installed, processing continues to operation310.

At operation 310, the thick client is activated by the user forreceiving data related to the service. Once the thick client isactivated, processing continues to operation 312.

At operation 312, a device key is requested to authenticate that theuser of the mobile device and the mobile device are authorized to accessthe service data. Processing continues at operation 314.

At operation 314, the cookie is validated to ensure that the mobiledevice is the mobile device authorized for viewing the service data. Inanother embodiment, a username/password may be used for validating theuser of the mobile device as capable of viewing the service data. Ifauthentication fails, the credentials of the user or the mobile device'scredentials may be challenged. If challenged, processing moves tooperation 316.

At operation 316, the user interface generating the rendered version ofthe service data may transition to request the user's credentials as aresult of the credential challenge. A user interface screen may bepresented for entering a user ID and password for authentication. Oncethe credentials are provided, processing returns to operation 312 wherethe mobile device may again be authenticated with the service server.Once authenticated, processing continues at operation 318.

At operation 318, device key pairs are generated for securing thecommunication of the service to the mobile device. A device record isgenerated indicating the device is accessing the service data at thistime. Processing continues at operation 320.

At operation 320, the device private key, device ID, and a next sequencenumber is returned to the mobile device. The device private key is usedto authenticate the data's source as the data is received by the mobiledevice. The device ID provides a unique identifier of the device for theservice, and may be used in future communications for expediting servicedata provisioning. The next sequence number indicates where the deviceis currently with regard to receiving the service data. For example, theservice may be a news service that sends news items to mobile devices.If the user has not received the news service items in a while, that isreflected in the sequence number. Every news item since the timeindicated by the sequence number may then be forwarded to the mobiledevice. Processing continues at operation 322.

At operation 322, the private key, device ID, and sequence number aresaved to the mobile device. Processing then continues at operation 324.

At operation 324, the actual data for the service is requested from theDVS server. The DVS server is sent an encrypted version of the deviceprivate key, device ID, sequence number, and hash, along with a versionnumber of the generalized thick client that the mobile device isrunning. Once the request is provided to the DVS server, processingcontinues with operation 326.

At operation 326, the DVS server decrypts the device ID, sequencenumber, hash, and version number using the public key of theprivate/public key pair and validates them. Processing then continues tooperation 328.

At operation 328, the DVS server returns a next sequence number, theactual service data, and any special actions (e.g., debug mode enable)encrypted using the public key to the mobile device. Processingcontinues to operation 330.

At operation 330, the generalized thick client interprets the servicedata and displays the top level page for the service. Once complete, theuser may then interact with the data, and processing moves to othertasks.

Process 300 is one aspect for provisioning the mobile device forreceiving service data for rendering on a mobile device. Other methodsmay be used. Additionally, a higher level description of the interactionbetween the DVS server and the mobile device is provided below in thediscussion of FIG. 4. It is understood however that the authenticationprocesses depicted in process 300 are equally applicable to the otherprocesses described herein.

FIG. 4 illustrates an operational flow diagram of an exemplary processfor the operation of a DVS server, in accordance with the presentdisclosure. Process 400 starts when a user experience (UX) definition isgenerated by a service and transmission of the UX definition to the DVSserver has commenced. Processing continues with operation 402.

At operation 402, the UX definition is received by the DVS server. Inone embodiment, the UX definition is provided as an Extensible MarkupLanguage (XML) file. Other embodiments may receive the UX definitionaccording to other formats. Processing continues at operation 404.

At operation 404, the UX definition file received from the service iscompiled into binary code. The binary code is a compact form of the datathat may be transmitted to the mobile device while preserving thelimited bandwidth of communication. Once the binary is generated,processing continues to operation 406.

At operation 406, the binary code is forwarded to the mobile device forrendering the user interface for the service. In one embodiment, thebinary code is forwarded according to the authentication processesdescribed above with relation to FIG. 3. Processing continues withdecision operation 408.

At decision operation 408, a determination is made whether an event hasoccurred with relation to the user interface rendered with the servicedata. An event notification may be received by the DVS server thatindicates such an event (e.g., a mouse click). If an event has occurred,processing continues with operation 410.

At operation 410, the event is routed to the service server forhandling. Once the event is routed to the service server, process 400ends and moves onto other tasks, such as routing responses back to themobile device, receiving additional events, or logging the mobile deviceout of the service session.

FIG. 5 illustrates a screen shot of a service user interface screenrendered by the generalized thick client described in the presentdisclosure. The rendered screen corresponds to a page of the service.Each particular page is defined by a series of widget definitions whichdescribe properties of the widget including its location on the page,bitmaps used for portions of the widget, fonts used and other propertiesthat affect its behavior and appearance. Zero or more behaviors areattached to each widget to handle events the widget may generate such asclick recognition events or other value changes. The behaviorscorrespond to actions, such as a move of focus to another widget, a moveto another page, sending a catalog or media request to the service andthe like. The layout of the widgets may be specified in absolute pixelcoordinates or by using constraint based layout. Constraints may be usedto specify a location or dimension relative to another widget, thescreen/page dimensions or the text font dimensions. This allows ameasure of device abstraction such that services do not have to providepage layouts for every different device screen resolution.

Many widgets may obtain their values by binding to the service provideddata tables. The table formats and data are specified by the service.The aforementioned music service example may include tables for theartists, albums, genres and tracks. Tables may contain one or morefields whose values link to rows in other tables. For example, theartist and album tables would likely link to the genre table to indicatethe genre for a particular artist or album. Similarly the album tablewould link to the artist table to indicate the artist of a particularalbum.

The binding may be associated in the page definition. A data binding isprovided for a widget to link to a particular data table. The table mayalso be filtered to entries with a particular value in a field in thetable. For example to display the albums by a particular artist, thealbum table may be filtered to rows in which the ArtistID field containsthe selected ArtistID value. There may be an optional formatspecification provided to translate the value stored in the table intotext that is displayable to the user. For example, a timestamp value(stored numerically) may be displayed in several different ways (h:mm,hh:mm, hh:mm:ss, etc.).

When the service has provided this DVS data to the DVS servers, aspreviously described, the data is “compiled” into a binary formatappropriate for the user's mobile device. This allows a layer ofabstraction between the services that use DVS and the device clients.Accordingly, the DVS may hide many of the differences between specificmobile device client implementations. For example, some devices may havethe ability to expose the native media player via the user interfacewidgets provided by the generalized thick client. Other devices may onlyoffer the ability to play audio via a native playback user interfacethat is separate from the service provided user interface. Thesedifferences may be abstracted so that the service does not require“knowledge” of the device specifics.

The device virtualization service may support mobile phones, mobilePDAs, laptops and desktops, television set to boxes and any othernetwork connected device with a user interface. The user interface isgenerated with better bandwidth utilization due to the binary packagingof the data before transmission to the mobile device, and with bettermemory utilization by retaining data storage for producing the servicecontent external to the mobile device. Additionally, service providersare able to provide a customized user interface without customized codefor the various mobile device types currently available.

The above specification, examples and data provide a completedescription of the manufacture and use of the composition of theinvention. Since many embodiments of the invention can be made withoutdeparting from the spirit and scope of the invention, the inventionresides in the claims hereinafter appended.

What is claimed is:
 1. A computer-implemented method for providing auser interface for a networked service on a mobile device, comprising:providing a generalized thick client to a mobile device, wherein thegeneralized thick client is configured to provide a user interface onthe mobile device for networked services; receiving a request for datafrom the mobile device; requesting the data from a service provider,wherein the data received from the service provider is deviceindependent; compiling the data from the service provider into anoptimized format; and responding to the device with the optimizedformatted data.